Path computation for tunnels of a computer network, e.g., label switched paths (LSPs), typically results in tunnels that traverse a single path, whether that path is a point-to-point (P2P) path, point-to-multipoint (P2 MP) path, etc. For example, tunnels in many Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE) networks (e.g., MPLS TE-LSPs) are computed using a constrained shortest path first (CSPF) algorithm. As those skilled in the art will understand, CSPF offers high flexibility and scalability, and is well-equipped to handle frequent topology changes, dynamic traffic demands, and resource availability changes. According to CSPF (for example), when a tunnel is built to satisfy a bandwidth constraint of “X”, the tunnel only follows a single path between a head-end node and one or more tail-end node of tunnels (e.g., the shortest path).
In the event the bandwidth constraint X is greater than the available bandwidth of links between the head and tail-end nodes, then no single path is available for the tunnel (i.e., the bandwidth constraint cannot be satisfied). Currently, if a tunnel requires a bandwidth greater than what is available along a single path between the head and tail-end nodes, the only way to satisfy the constraint is to establish multiple tunnels between the head and tail-end nodes whose reserved bandwidths are each smaller than X and when combined total X (or greater than X). Similarly, if there are multiple parallel links/circuits available between a pair of nodes along a tunnel's path, the tunnel may only utilize one of them. In order to utilize the multiple parallel links, multiple corresponding tunnels must be created from a head-end node where each follows the same path but over a different parallel link.
In either situation above, the respective head-end node of the multiple tunnels is thus required to load balance traffic between the multiple tunnels. Also, in many instances, these multiple tunnels share various links between the head and tail-end nodes (e.g., where those shared links have available bandwidth greater than X), resulting in an increased number of tunnels on those shared links. For example, as mentioned above, if two intermediate nodes along a path have ten parallel links between them, each having one tenth of the bandwidth X, a head-end node would need to establish ten tunnels along the entire path in order to utilize those ten parallel links. As such, each other link/node along the path may be required to maintain those ten tunnels. These multiple tunnels may be a burden to the head-end node and intermediate nodes to maintain, and generally do not scale well (particularly for long paths requiring many tunnels).
Note, also, that one or more of these issues apply to backup tunnels, such as those offering bandwidth protection where it is difficult to compute a single backup tunnel that supports the entire amount of protected bandwidth. In particular, multiple backup tunnels at a point of local repair (PLR) for a protected tunnel are generally difficult to maintain, as will be understood by those skilled in the art (e.g., selection of a single backup tunnel requiring packing algorithms, etc.). Also, even if a particular path could satisfy the bandwidth constraint of a backup tunnel it may be more desirable to spread the backup load amongst several paths if possible.